Method for synchronization of policy cache with various policy-based applications

ABSTRACT

A hardware-based policy engine that employs a policy cache to process packets of network traffic. The policy engine includes a stream classifier that associates each packet with at least one action processor based on data in the packet, and the action processor further acts on the packets based on the association determined by the stream classifier.

RELATED APPLICATIONS

[0001] This application claims the benefit of priority to U.S.Provisional Patent Application No. 60/112,976, filed Dec. 17, 1998.

TECHNICAL FIELD

[0002] The present invention relates to policy-based network equipmentand, in particular, to policy-based network equipment that employs afavorable division of hardware and software to provide both performanceand flexibility.

BACKGROUND

[0003] Some typical policy-based computer network applications areVirtual Private Networks (VPN), Firewall, Traffic Management, NetworkAddress Translation, Network Monitoring, and TOS Marking. In general,the policy-based application has access to the network media through anoperating system driver interface. In a typical network architecture,the policy-based application examines every packet coming in from thenetwork along the data path, compares it against flow classificationcriteria, and performs the necessary actions based upon the policiesdefined in a policy database.

[0004] Today's policy-based applications are challenged with several keyissues. These issues can be major inhibitors for the future growth ofthe emerging industry:

[0005] 1) Flow classification overhead—Flow classificationspecifications can be complicated and lengthy for each network service.As can be seen from FIG. 1, in a conventional policy-based application,each packet compared with potentially hundreds of rules in order to findthe matching one and determine the proper action specifications. Withstateful applications, state tracking is even more time consuming.Multiple network services on a single system simply make matters worse.

[0006] As is also shown in FIG. 1, the process of flow classificationand action processing may repeat for many iterations as multiplepolicies are activated at the same time. For example, a VPN (virtualprivate network) application may comprise Firewall Policy, IPSEC Policy,IPCOMP (IP compression) policy, NAT (Network Address Translation)Policy, QoS (Quality of Service) policy, Monitoring Policy, L2TP/PPTP(L2 Tunnel Protocol/Point To Point Tunnel Protocol) Tunnel Policy, andso on.

[0007] The flow classification is a rule based operation that can bevery flexible to tune to application needs. For example, it may define arule to identify packets with a pattern of any random byte within apacket, and/or across many packets. The flow classifiers may also differper action processor for performance optimization. As a result thematching criteria used by a flow classifier to classify a flow mayinclude a specific value, a range, or wildcard on interface portnumbers, protocols, IP addresses, TCP ports, applications, applicationdata, or any user specifiable criteria. The distinctions of variousimplementation makes it difficult to cache a flow with its decision inmany ways.

[0008] 2) Flow classification technique is evolving—Flow classificationand analysis technique is more than just looking into the packet'saddress, port number and protocol type and or other header information.It often involves state tracking for newer applications. This techniqueis being continuously modified and, therefore, is not practicallyappropriate for a hardware based implementation. Furthermore, flowclassification techniques are often viewed as key differentiatersbetween vendors.

[0009] 3) Action execution speed.—Once the classification process iscomplete, the proper actions need to be executed. Some of the actionsare simple like a discard or forwarding decision for a firewall, whilesome others are extremely time consuming, like triple-DES encryption andSHA hashing algorithm or QOS scheduling algorithm. Software basedimplementations cannot keep up with the bandwidth expansion as newer andfaster media technologies are employed.

[0010] 4) Integrated services—As more and more policy-based applicationsbecome available, it is desirable to provide integrated services on asingle platform because this ostensibly reduces policy managementcomplexity, avoids potential policy conflicts, and lowers the TCO (TotalCost of Ownership). On the other hand, integrated services impose a verylarge computing power requirement that cannot be practically achievedwith off-the-shelf general purpose machines. A disadvantage of theconventional architecture is that, because it is primarilysoftware-based, it is relatively high overhead. However, preciselybecause it is software-based, it is quite flexible.

[0011] What is desired is a policy architecture has the flexibility ofpresent flow classification systems, but that also has lower overhead.

BRIEF DESCRIPTION OF THE FIGURES

[0012]FIG. 1 is a block diagram illustrating conventional flowclassification and action processing.

[0013]FIG. 2 is a block diagram illustrating the a broad aspect of apolicy architecture in accordance with an embodiment of the invention.

[0014]FIG. 3 is a block diagram illustrating details in accordance withone embodiment of FIG. 2.

[0015]FIG. 4 illustrates more details of how the FIG. 3 architecture isemployed to process network data.

[0016]FIG. 5 also illustrates more details of how the FIG. 3architecture is employed to process network data.

DETAILED DESCRIPTION

[0017] As shown broadly in FIG. 2 and in greater detail in FIG. 3, inaccordance with one embodiment of the invention, an architecture 100 forapplying policies to network data traffic allocates the application ofpolicies between software and hardware such that the system is flexibleyet efficient.

[0018] The architecture 100 includes three major components—aPolicy-Based Application 102, a Policy Engine API 104 (“API” stands forApplication Program Interface”) and a Policy Engine 106. As can be seenfrom FIGS. 2 and 3, the policy-based application 102—such as a firewall,virtual private network (VPN), or traffic management—is typically a“legacy” software program residing on a host, equipped with its ownpolicy database 202 and flow classifier logic 204.

[0019] The policy engine API 104 serves as an interface between thepolicy application 102 and the policy engine 106 (via a system bus 105).The policy engine 106 is a purpose-built hardware (preferably running atwire speed) that operates on input network traffic and network policiesand that outputs regulated traffic flows based upon the networkpolicies.

[0020] In a typical embodiment, the policy engine API 104 provides thepolicy-based application 102 access to all the media I/O through ageneric operating system driver interface. In addition, the API 104allows the application 104 to invoke acceleration functions (shown inFIG. 3 as application processors 206, or “AP's”) provided by the policyengine 106. The application processors 206 operate based on the streamclassifier 207 of the policy engine 106 determining that a packetbelongs to a particular stream and activating the appropriate actionprocessors 206 according to action specifications 210 in a policy cache209. That is, overall system performance is enhanced by virtue of theappropriate acceleration functions (action processors 206) of the policyengine 106 being activated to regulate the network traffic.

[0021] Before proceeding, several terms are defined in the context ofFIGS. 2 and 3. The definitions provided herein are meant to beexplanatory, and not necessarily limiting when a similar or identicalterm is used in the claims.

[0022] Service

[0023] A service in a policy-based network defines a network application102 that is controlled and managed based on a set of policies. Typicalservices are firewall, VPN, traffic management, network addresstranslation, network monitoring, etc.

[0024] Policy

[0025] Policies (normally defined by network managers) are collectivelystored in a policy database 202 accessible to the policy-basedapplications 102 (even conventionally) and describe network trafficbehaviors based upon business needs. A policy specifies both whattraffic is to be subject to control and how the traffic is to becontrolled. Thus, a policy typically has two components—a flowclassification specification 203 a and an action specification 203 b.

[0026] Flow Classification Specification 203 a

[0027] A flow classification specification 203 a provides the screeningcriteria for the flow classifier logic 204 to sort network traffic intoflows. A flow classification specification 203 a can be very elaborate,as detailed as defining a specific pair of hosts running a specificapplication. Alternately, a flow classification specification 203 a canhave a simple wildcard expression.

[0028] Action Specification 203 b

[0029] An action specification 203 b describes what to do with packetsthat match an associated flow classification specification 203 a. Theaction specification 203 b can be as simple, for example, as a discardor forward decision in the firewall case. It can also be as complicatedas IPSec encryption rules based on a SA (Security Association)specification.

[0030] Flow

[0031] All packets that match the same flow classification specification203 a form a flow.

[0032] Flow Classifier

[0033] Referring again to FIG. 3, a policy decision is at leastinitially derived by a policy-based application from the policy database202. As discussed above, a flow is a stream of correlated packets towhich policy decisions apply. With the described embodiments inaccordance with the invention, referring again specifically to FIG. 3,for at least some of the packets, a flow classifier 204 classifies thepacket according to one or more classification specifications 203 a andfinds one or more corresponding action specifications 203 b. The foundaction specifications 203 b are then provided to the policy cache 209for later execution by the policy engine 106 to enforce the policy.

[0034] Policy Binding

[0035] Policy binding is the process of the flow classifier 204 bindinga stream with its associated action specification and loading theappropriate entries (stream specification 208 and action specifications210) into the policy cache 209.

[0036] Stream

[0037] A stream is an “instantiation” of a flow—packets that have thesame source and destination address, source and destination port, andprotocol type. (Optionally, the application can add the input and outputmedia interface to the stream classification criteria in addition to thepacket header if desired.) Packets may be sorted into streams, and aflow may include one or more streams. All packets belonging to the samestream are to be regulated by the same policy.

[0038] Policy Cache 209

[0039] At the completion of the policy binding process, an entry for agiven stream is created on the policy engine which contains all thepolicy information required to subsequently process data of the stream

[0040] Integrated Services

[0041] When multiple network services are to apply to the same flow,this is called “Integrated Services”. Integrated Services simplify themanagement of various service policies, minimize potential policyconflicts and reduce TCO (Total Cost of Ownership).

[0042] Stream Specification

[0043] A stream specification 208, shown in FIG. 3 held in policy cache208 is the criteria used by the stream classifier 207 to uniquelyidentify a stream. In one embodiment, the stream specification 208 iscompared to a 5-tuple in a packet header—source and destination address,source and destination port, and protocol type.

[0044] Action Processor 206

[0045] Each action processor 206 executes an action based upon an actionspecification 210 in the policy cache 209.

[0046] Packet Tagging

[0047] Certain applications (e.g. Network Monitoring) would like toreceive flows based on the flow classification specification and wouldprefer that flow classification be performed for them. Packet tagging isa way of tagging all incoming packets with an application specified “tag

[0048] Policy-Based Application

[0049] A policy-based application provides a service to the networkusers. This service is managed by a set of policies. Firewall, VPN andTraffic Management are the most typical policy-based applications. Asthe industry evolves, policy-based applications are likely toconsolidate onto a single platform called Integrated Services.Integrated Services has the benefits of centralized policy managementand lower cost of ownership.

[0050] Referring still to FIG. 3, the population and use of the policycache 209 is now discussed in greater detail. As discussed above, thepolicy-based application 102 (typically a legacy application) isequipped with its own policy database 202 and flow classifier logic 204.Some of the packets of a stream are provided (via a data path shownlogically as 401 in FIG. 3) to the flow classifier 204. The flowclassifier 204 uses the policy database 202 to determine the actionspecifications 203 b that correspond to the policies of the flow towhich the stream belongs. The action specifications are provided (viathe path shown logically as 402 in FIG. 3) to the policy cache 209. Itshould be noted that multiple packets may be required for moresophisticated flow classification (stateful packet inspection), sincethe policy decisions (action specifications) may come from differentapplications which may have implemented different flow classifiers. Inthose cases, the application's flow classification logic keeps track ofthe flow's state until a matching criteria is met. Preferably, though,just enough packets of a stream are provided to the flow classificationlogic 204 via the logical path 401 to properly determine the actionspecifications 203 b for the stream. At the end of the “learning phase”,the application software 102 has uniquely identified a policy for theincoming packet stream

[0051] Subsequent packets of the stream are then provided directly tothe stream classifier 207 of the policy engine 106 via the logical datapath 403. Using the policy cache 209, the stream classifier 207determines which action processors 206 are to be activated for thepackets of the stream. Specifically, the stream classifier 207 matchesthe packets to a particular stream specification 208 and then, using thecorresponding action specifications 210, activates the proper actionprocessors 206. Significantly, these “subsequent packets” can be actedupon without any interaction to the “host” policy-based application 102.The application need not “see” any packets belonging to that streamafter the binding (unless the stream is actually destined for thehost.). The action processors are specialized in executing specificaction specifications, preferably at the wire speed.

[0052] Thus, in summary, upon the completion of the policy binding“learning” process, the policy engine 106 may immediately take controlof the bound stream and execute the appropriate actions in accordancewith the action specifications 210 in the policy cache 209 without anyintervention from the “host” (policy-based) application. This methodalso relieves the policy engine 106 hardware from doing complicatedpattern matching because it can simply compute a hash value (or use someother identification function) from the well known fields (whichuniquely identify a stream) of the packet to find its correspondingpolicy decisions (action specifications 210). The classification neednot be done more than once for each packet even though there may bemultiple applications. As a result, massive computing power is notrequired to do the classification on an ongoing basis. A benefit isinexpensive hardware cost for very high performance policy-basedapplications.

[0053] It can be seen that in accordance with the present invention, useof the policy engine and policy cache not only addresses many if not allof the performance considerations discussed above in the Background, butalso preserves a great amount of flexibility in setting network policiesand the following consderations are taken into account.

[0054] 1) Time-to-market for application developers—Since time-to-marketis a major concern for application vendors, the PAPI design minimizesthe development effort required by the application developers in orderfor the existing applications to take advantages of the policy engine'senhanced performance.

[0055] 2) Maintain flexibility for developers' value-added—PAPI mayallow application developers to enhance or maintain their value-add sothat vendors' differentiation is not compromised.

[0056] 3) Platform for integrated services—PAPI has the model of anintegrated services platform in mind. Application developers can, overtime, migrate their services into an integrated platform withoutworrying about the extensibility of the API and the performance penalty.

What is claimed is:
 1. A hardware-based policy engine to manage trafficover a computer network, comprising: an input data path to receivepackets of network traffic constituting at least one stream; means forproviding at least a portion of each stream to a host processorexecuting a policy-based software application and for receiving from thehost processor at least one action specification associated with saideach stream; means for maintaining a policy binding database based onthe at least one action specification received from the policyapplication processor; at least one action processor configured to acton the packets of network traffic; and a stream classifier thatdetermines an association of each packet with at least one actionprocessor based on data in the packet that uniquely identifies thestream to which the packet belongs, the classification determinationbeing made in cooperation with the policy-binding database and withoutthe involvement of the host processor wherein the at least one actionprocessor acts on the packets of network traffic based on theclassification association determined by the stream classifier.
 2. Thepolicy engine of claim 1, wherein the policy binding databasemaintaining means includes means for maintaining in the policy findingdatabase a plurality of database records, each record including an entryfor a stream specification and an indication of one or more actionspecifications.
 3. The policy engine of claim 2, wherein the streamclassifier includes: means for determining, for each packet, whichrecord of the policy binding database includes a stream specificationthat corresponds to the unique identification information in the packet;and means for determining the association of that packet with the atleast one action processor based on the indication of at least oneaction processor in the determined record.
 12. (New) The system of claim11, wherein the stream classifier computes a hash value from a field inthe packet and uses the hash value to select one action specification.13. (New) The system of claim 11, wherein the policy cache has aplurality of stream classifications and each stream classification beingassociated with multiple action specifications.
 14. (New) The system ofclaim 11, wherein the policy engine stores the action specificationsinto the policy cache.
 15. (New) The system of claim 11, wherein thepolicy engine provides a few packets of the flow to a flow classifier.